Such a long primer diff. It seems like I enabled redundant-expr by accident or something like that. I will check it tomorrow.

Diff from mypy_primer, showing the effect of this PR on open source code:

bandersnatch (https://github.com/pypa/bandersnatch)
+ src/bandersnatch_storage_plugins/s3.py:62: error: Unused "type: ignore" comment  [unused-ignore]

core (https://github.com/home-assistant/core)
+ homeassistant/components/recorder/migration.py:2283: error: Unused "type: ignore" comment  [unused-ignore]
+ homeassistant/components/recorder/migration.py:2305: error: Unused "type: ignore" comment  [unused-ignore]
+ homeassistant/components/schedule/__init__.py:76: error: Unused "type: ignore" comment  [unused-ignore]
+ homeassistant/components/twentemilieu/calendar.py:73: error: Unused "type: ignore" comment  [unused-ignore]

pyodide (https://github.com/pyodide/pyodide)
+ src/py/pyodide/_state.py:21: error: Incompatible types in assignment (expression has type "pyodide._state.<subclass of "ModuleType" and "JsProxy">2", target has type "pyodide._state.<subclass of "ModuleType" and "JsProxy">")  [assignment]

Regarding pypa/bandersnatch and home-assistant/core, the diff looks good. Regarding pyodide/pyodide, I neither understand why this error is emitted now nor why it is emitted in general (confusing error message). Maybe you know this behaviour already. I could investigate later.

I can reproduce the pyodide problem with Mypy 1.14.1 if I repeat the isinstance check by writing it twice (instead of writing it in a loop), so it is not caused by the change proposed by this PR:

class A: ...
class B: ...

a: A
if isinstance(a, B):
    c = a
if isinstance(a, B):
    c = a  # E: Incompatible types in assignment (expression has type "__main__.<subclass of "A" and "B">1", variable has type "__main__.<subclass of "A" and "B">")  [assignment]

It's sort-of caused by the change here: at the final iteration (when partials don't change) you accept the body once again. This breaks any such inference propagated outside from isinstance (used to infer type of something external to the loop).

I don't believe this is a big deal though (various issues arise with building dicts/lists/... in a non-trivial loop, it's often necessary to annotate the collection anyway).

I do not entirely understand what you are trying to say. However, the same problem can already occur with earlier Mypy versions (that do not check for the number of partials like the master branch Mypy does now) when writing a loop like this:

class A: ...
class B: ...

a: A
cs = []
x: int | str
x = 1
for i in range(2):
    if isinstance(a, B):
        cs.append(a)  # E: Incompatible types in assignment (expression has type "__main__.<subclass of "A" and "B">1", variable has type "__main__.<subclass of "A" and "B">")  [assignment]
    x = "x"

Here, update_from_options causes that the loop body is accepted twice.

So, in my opinion, this issue does not need to bother us in this PR. However, as related false positives would likely be reported more often (in case this PR gets accepted) and as I am curious about the underlying cause, I could try to fix it in a separate PR.

I couldn't track when we started distinguishing ad-hoc intersections, it looks like it is there since long time ago. Anyway, IMO instead of using gen_unique_name() we can simply pull an existing TypeInfo if it is in the current symbol table. Maybe I am missing something, but IIUC these fake TypeInfos should behave as close to the "real" intersections as possible.